Inventory Status states summarized:

     *    <li>NEW: Auto-discovered but not yet imported into the inventory.</li>
     *
     *    <li>IGNORED: Auto-discovered but explicitly moved to a state that will suppress it from showing up in future
     *                 discoveries.  Resources in this state will not be shown in the inventory browser.</li>
     *
     *    <li>COMMITTED: Resources in this state will be visible in the inventory browser.  The act of importing
     *                   resources changes their state from NEW to COMMITTED.  Note: resources that are factory-created
     *                   or manually added will also appear in the inventory browser and, thus, will be COMMITTED.</li>
     *
     *    <li>DELETED: Resources can be removed from the remote box, which will flip their status to DELETED to suppress
     *                 them from showing up in the inventory browser.</li>
     *
     *    <li>UNINVENTORIED: Resources can be removed from the inventory.  Since this is an expensive operation, these
     *                       resources are temporarily marked as UNINVENTORIED which will suppress them from showing up
     *                       in the inventory browser.  Then, in the background, all history will be purged for these
     *                       resources, after which they are removed from the database completely.</li>

Current Behavior

RI - Resource in database RM - Resource being manually added
UNINVENTORIED state is a special state that we can completely ignore. The path with that status is identical to NEW.

There are several flaws with the current release implementation:

• The InventoryManager attempts to detect existing resources with the same plugin configuration identifier and only if NOT COMMITTED, then tries to apply the latest plugin config. This does not address that NEW/IGNORED/DELETED are distinctly different states which may need to be treated differently.

• The exposed remote api for Manual Add promises to return the existing Resource(regardless of inventory status) if the plugin configuration identifies a previously indexed resource. That implies certain configuration/status after manual import that is unclear.

• This whole approach assumes that the UI/api users understand the various different details of InventoryStatus(NEW,IGNORED,DELETED,COMMITTED). The users shouldn't have to to successfully import their resources.

• The autodiscovery queue can i) hold onto a resource(NEW) state even after that process has been shut down, unknown to the user. You'll need to try to import that resource into RHQ and then remove to clear that up. This is a confusing state to an administrator which can scan the process table and see no current processes for their managed resource.

• What should happen when a resource has already been indexed and is in one of the following states is unclear: (IGNORED,DELETED) since in each case the user has made explicit requests to put that same resource in a different state before now attempting to manually add it. If we take a step back the RHQ administrator is now attempting to apply contradictory states to the same resources. Before they had explicitly marked the given resource as either IGNORED or DELETED. By attempting a manual add using a key that had already existed they're now requesting that the same resource be brought back into the inventory, which is contradictory to the first point and likely unintentional.

What is the customer looking for?

That is a great question here. There are several competing opinions in the absence of real input from customers on this one:

1. If my manual add requests conflict it should fail indicating the customer should use existing plugin configuration update ui/apis available.

2. If my manual add request maps to an existing resource for any reason then RHQ should take this new state as the correct one.

3. If my manual add request maps to an existing resource RHQ should try to do what makes sense here even though this behavior is currently covered by resource update workflows.

While not an actual customer, the EWS team had this to say about their thoughts on implied behavior:

> Import. Can you indicate what do you think the EWS customers would
> expect to be a valid response if they tried to Manually Add a Tomcat
> instance that was already in inventory?

Would it be possible to have a error telling it is already in the inventory?

>  How about a resource that
> they'd marked as IGNORED?  Or marked as DELETED in the RHQ UI?

It is possible to detect it and have a error message that tells that
they may be doing something wrong and point they to either already
"marked as IGNORED" or "marked as DELETED" so they can UN-IGNORE and
UN-DELETE the tomcat?

>
> These are questions that are not well described by our current
> interface.  Can you provide some feedback from the EWS perspective?

I only use JON/RHQ to check and fix the BZ reported to me, my feelings
are that the basic operations are already not easy to do and things like
manual import are for experienced users or special cases where the
automatic stuff doesn't work may be something in the frame should tell
"experienced users / special cases only".

Specification of behaviors after the proposed changes.